Method and Device For Migrating a Specifically Encrypted Access Object From a First Terminal Unit to a Second Terminal Unit

ABSTRACT

The present invention provides a method, a migration server and a terminal device mor migrating specifically encrypted access objects (such as e.g. a license) between mobile terminals such as e.g. computers and/or cellular telephones. Method for migrating a specifically encrypted access object from a first terminal unit to a second terminal unit is performed according to the invention, by a migration server of a communication network. The method comprises receiving via said communication network, a first specifically encrypted access object of said first terminal unit and identification data related to said first terminal unit and to a content said first specifically encrypted access object is destined for (e.g. an application). Then identification data related to said second terminal unit and a request for issuing a second specifically encrypted access object for said second terminal unit are received at the server via a communication network. The server performs a check if said request is authorized and generates a second specifically encrypted access object for said second terminal unit, being destined for said content, if said request is authorized. The generated second specifically encrypted access object destined to said second terminal unit is then sending via said communication network, to said second terminal.

The present invention relates to the field of digital rights managementusing online downloads of specifically encrypted access objects (such ase.g. a license) to mobile terminals such as e.g. computers and/orcellular telephones. It also relates to an online licensing system,wherein one or more specifically encrypted access objects (e.g.licenses, rights objects or access objects) are required to execute acontent (such as music, video, games, software or text) on a terminaldevice.

At present it is not possible, however, to sell specifically encryptedaccess objects (SEAOs) once downloaded to somebody else. Presently theexecution and/or acquisition of protected content, for example a game ona terminal device, follows the Open Mobile Alliance Digital RightsManagement (OMA DRM) mechanisms. To execute a game, one or several SEAOsmust be available in the terminal device. Instead, the developers ofSEAOs have only aspired to prevent any possibility to pass on SEAOs tosomebody else. The digital rights access mechanisms have only beendeveloped with a main intention to prevent that a user may get access tocontent without having paid for an SEAO. All efforts have been directedto ensure that a user is prevented from distributing different copies ofthe content and the SEAOs (e.g. a license) to an indefinite arbitrarynumber of other devices or friends. These efforts have led to SEAOsallowing the execution/usage of a certain content only on a certaindevice or only with a certain unit.

These efforts have in turn led to frustrated users not being able to usea SEAOs on e.g. a newly purchased device. Additionally, a re-selling ofa purchased SEAO is actually not possible, as the user is not able todecrypt and re-crypt a SEAO, as otherwise there would be no need for anykind of access objects.

During the last years DRM methods became very popular to protect digitalcontent against illegal copying on the basis of new DRM laws that becamevery popular to protect digital content against previously legalcopying.

Before a protected digital content can be used on any kind of device(such as a Personal Computer, mobile phone, Personal Digital Assistantetc.) a valid specifically encrypted access object (SEAO) is required.The term “SEAO” in the following text is intended to cover all elementsthat are required to make protected digital content usable on a specificdevice. The expression “SEAO” may be comprised of the items such aslicenses, digital rights objects and e.g. public key coded rightsobjects. That is, the “SEAO” represents any kind of code that isrequired to execute or use a content such as a program or video, audio,picture or text data.

Presently, the device may receive a SEAO on many different ways. A SEAOcan be obtained via any kind of offline secure storage medium (such ase.g. an SD-card or a Secure MMC), a pluggable module (with a hard-codedSEAO) or online via Internet download or communication network download.Due to low costs on the one hand and due to the permanently increasingnumber of Internet-connected devices on the other hand, theInternet-based and communication network download of SEAOs has becomevery common for DRM protected digital content.

Hence the secure online download of SEAOs is well specified by popularstandards (such as e.g. the OMA DRM standard). In the scope of futuregaming platforms common DRM technologies (such as the OMA DRM) are takeninto consideration to protect games (and additional game content)against illegal usage. The “storage” of a SEAO on any kind of medium inthe following is to be understood so that the SEAO is bound to aspecific individual unit such as a device or a storage medium. This caseis not to be mixed up with a common backup scenario, in which it isallowed to copy a SEAO to a storage medium but the binding of the SEAO(to a certain unit) remains unchanged. In the following text a SEAO isbound to a certain terminal or a certain storage device. In thisframework it is still possible to use a backup copy of a certain SEAO onanother storage medium. In case of a storage bound SEAO it is howevernot possible to execute said backup from the backup medium, with thesame storage medium, as the specifically encrypted access object (SEAO)does not fit to the identification of the backup storage medium. In caseof a terminal bound SEAO it is possible to execute said backup from thebackup storage medium, on the same terminal with the backup storagemedium. However, it is not possible to execute any content with thestored SEAO on another terminal, as the SEAO does not fit to theidentification of the other terminal.

Presently it is not possible to provide means to “migrate” or “move” aSEAO from a first storage medium to a second storage medium so that itis possible to execute a protected content from the second storagemedium, i.e. to adapt the SEAO to the identification of the secondstorage medium.

However it could be desirable to enable a user to “migrate” or “move” aSEAO from a first storage medium to a second storage medium so that itis possible to execute a protected content from the second storagemedium, i.e. to adapt the SEAO to the identification of the secondstorage medium.

According to a first aspect of the present invention a method isprovided to “migrate” or “move” a SEAO from one terminal unit to anotherterminal unit. In the following text the expression “terminal unit” willbe used for “terminal devices” in the sense of a certain entity alicense or a SEAO may be coded for. That is, a terminal device such as ae.g. a mobile telephone, a communication enabled computer device such asa communicator or merely a storage medium is intended.

It is intended to execute the method in a migration server directly orindirectly connected to a communication network. The communicationnetwork may be WLAN, Bluetooth and other, even wired data connections.The invention can also be implemented for Notebooks, PDAs and PCs. Themethod of the present invention starts with receiving via saidcommunication network a first SEAO of said first terminal unit andidentification data related to said first terminal unit and to a contentsaid first SEAO is destined for. The method further comprises receivingidentification data related to said second terminal unit and a requestfor issuing a second SEAO for said second terminal unit via acommunication network.

The method further comprises checking if said received request isauthorized, and generating a specifically encrypted access object (SEAO)for said second terminal unit, being destined for said content, if saidrequest is authorized. The method is terminated by sending saidgenerated SEAO destined to said second terminal unit via saidcommunication network.

The present invention provides a new way to migrate the ability toexecute or use a certain content from a first terminal unit to anothersecond terminal unit.

The method comprises or starts with a reception of data indicating thata SEAO of a first terminal is requested to be transferred immediately orlater to another, second terminal unit. The SEAO is identified by thereception of said first SEAO of said first terminal unit, saididentification data related to said first terminal unit and to saididentification data related to content said first SEAO is destined for.That is, the present invention relates to SEAOs that are specificallycoded according to a certain hardware component (i.e. the terminal unit)and according to a certain content to be executed or used (e.g. asoftware, audio, video, picture, map, text and/or other “display” data).By transferring said data via a communication network said it is nolonger necessary to visit a specific service point of the provider ofthe device the SEAO is destined for.

It may be noted that both receiving processes, the receiving of a firstSEAO of said first terminal unit, its identification and the receivingof identification data related to said second terminal unit may occur atthe same time (e.g. in one transmission from a single sending-terminalunit) or with a certain time difference.

It is to be added further that the first SEAO and respective data andsaid identification data related to said second terminal unit may bereceived from a single sender terminal unit or may be received each fromthe respective first and second terminal units.

In a simple embodiment both data may be received from a single (i.e. thesecond) terminal during a single transmission. This implementationassumes that the data related to the first device have previously beentransferred from the first terminal unit to the second terminal unit.

The checking operation if said request is authorized can be embodied ina simple version by a plausibility check. A plausibility check impliesonly if the data related to the first terminal unit indicate that acertain content could be executed or used on said first terminal. Whenthe result of the check indicates that this is possible it is assumedthat the owner of the first device wants to execute or use a specificcontent on said second device and a specifically encrypted access object(SEAO) for a second terminal unit can be generated.

Here it is also to be noted that the checking operation may compriseadditional checking subroutines such as checking a database if said SEAOfor the first device has been generated or not. It should be mentionedthat a checking operation may be implemented if or that said first SEAOhas already been used for requesting a “migrated” SEAO for anotherdevice or not, and if so the “migration” may be rejected. It is alsoenvisaged to implement a storing operation in the process to determinethe number of secondary SEAO generated on the basis of the first SEAO.

However, the method may be embodied in a more complex manner byimplementing additional check up intermediate steps like checking ife.g. a period of validity said first SEAO has been provided with has runoff.

If the request for the SEAO is authorized, i.e. has passed all checks,the server generates said requested second SEAO for said second terminalunit, being destined for said content, and transmits said second SEAO tothe second terminal unit.

It may be noted that in case that SEAOs are used that are specific for acertain storage element said first and second SEAOs are received fromand sent to a same terminal device (wherein only the storage unit insaid device is exchanged).

That is, (in contrast to commonly known backups) also the binding of aspecifically encrypted access object (SEAO) is changed to the newterminal unit (e.g. storage medium).

In this framework it is also envisaged to code said first SEAOs in thefirst terminal unit, transfer it to the second terminal unit prior tothe transfer of the first SEAO to the migration server. It iscontemplated to code this first SEAOs with a public key of said firstterminal unit.

However the SEAO can only be used for executing or using a content ifand when the first SEAO has been decrypted and encrypted at themigration server for the second terminal unit. This may comprise that ina preceding step the SEAO of the first device has been madeunserviceable.

The transfer of a SEAO from a first terminal unit to the second terminalunit may be implemented by the exchange of a pluggable memory devicesuch as MMC storage medium. It is also contemplated to transfer saidSEAO from a first terminal unit to the second terminal unit via e-mail,multimedia messages (MMS), via a GPRS connection.

It is also contemplated to transfer an identification of the secondterminal unit from the second device to the first device, followed bythe migration of the (first) SEAO to the (second) SEAO, followed by thetransfer of the second SEAO from the first terminal to the secondterminal. This embodiment may have the advantage that a user of thefirst device may act as a final authorization instance with the abilityto interrupt the method directly before the transfer of the second SEAOto the second unit.

In an example embodiment of the present invention said method furthercomprises generating a voucher data object (VDO), for the generation ofa SEAO for another terminal unit for said content, and sending said VDOto said first terminal unit via said communication network. The methodof the present embodiment further comprises receiving said VDO from saidsecond terminal unit via said communication network. In this embodimentsaid checking operation if said request is authorized comprises checkingif said received VDO is valid.

It is envisaged to implement a reception of a request for a VDO from thefirst terminal device.

This embodiment enables a user to separate the actions required from thedonor of the first specifically encrypted access object (SEAO) and theacceptor of the SEAO. Is it for example not necessary to pass specificdevice data from the first terminal unit to the second terminal unit.Additionally the user of the first terminal unit may offer the SEAOwithout knowing anything about the receiving terminal unit.

SEAOs downloaded from an online server are bound (e.g. due to uniqueterminal unit encryption key) to the requesting terminal unit. A passingon of SEAOs is possible with the involvement of an online connectivity.The online migration server must be able to upload the (first) SEAOs orat least parts of the SEAO to identify clearly the SEAOs. Once the SEAOare uploaded and identified by the server the SEAO in the mobileterminal unit has to be deleted. The mobile terminal unit will receivethe voucher data object (VDO). The VDO can be implemented e.g. by anon-serial unique number. This “serial number” (of the VDO) can betraded to sell the SEAO of e.g. a game. The buyer of the VDO will beable to download the related SEAO.

Once a user of a terminal unit receives said VDO of e.g. a game he hasto login to the migration server or the specifically coded access objectprovider (or an online portal of e.g. games publisher). The terminalunit user has to forward the VDO and can download all SEAOs related tothis VDO. Download of SEAOs will be granted after validity check of thee-voucher by the online portal.

In another example embodiment of the invention said receiving of saididentification data (related to said second terminal unit) and saidrequest for said second SEAO (for said second terminal unit) and saidreceiving of said voucher data object are performed substantiallysimultaneously. In this embodiment said generating of said second SEAOfor said second terminal unit, and said sending of said generated secondSEAO destined to said second terminal unit are performed substantiallysuccessively.

This embodiment puts together the actions required to cash in a voucherdata object at a server. The claim illustrates the (at least semi-)simultaneous transmission of said identification data related to saidsecond terminal unit of said request for issuing a second specificallyencrypted access object (for said second terminal unit) and said VDO viasaid communication network. That is, a user connects a server,identifies himself (and/or his device) and sends a VDO for cashing in.In response to receipt thereof the server generates said second SEAO forsaid second terminal unit, and subsequently sends said generated secondSEAO (destined for said second terminal) to said second terminal. Thatis, the second part of the method can be performed in a short time toenable a quick access for a user to enable quick use of specificallyencoded contents. This embodiment may be regarded as a conversion of aVDO to a (second) SEAO.

It is envisaged to use coded or encrypted VDOs. An encrypted VDO maycomprise an identification of the first device used to request the VDO.It is also contemplated to use a serial number or a uniquecharacteristic VDO number or signature for identifying each singleissued VDO. It may be contemplated to implement data in the VCOcomprising information about the issuing instance, the originating firstterminal device and the content to be executed (including e.g. anidentification and/or a version number of said contents). It is to benoted that the VDO may also be used to provide or distribute updates forcertain contents. In case that e.g. a firmware or a downloaded contentsturns out to be faulty, defective or outdated the VDO may be used toenable a user to get e.g. “Version 5.3 SEAO” for a voucher obtained by a“Version 5.0 SEAO”.

In a further example embodiment of the present invention said methodfurther comprises storing said VDO in a memory of said migration server.By storing said VDO in a memory of said server a kind of double entrybookkeeping can be implemented in the migration server. This storageoperation may be connected with a timestamp and/or flag for “having beencashed in” or “have not been cashed in yet” of said VDO. Thus all dataof issued, circulating, and cashed in VDOs are available to the providerof the VDO.

It may be noted that said stored VDO may be deleted with the cashing inof the VDO. It is also envisaged to store the VDO together with saidgenerated second specifically coded access object. This can contributeto prevent that a voucher is copied and sent twice to said migrationserver.

It may be envisaged to implement a specific VDO database in the server.This implementation may be used to provide a kind of (semi-) anonymousdatabase for countries with restrictive data protection regulations. Incontrast to a nearly not achievable database for storing all circulatingSEAOs (due to hangover SEAOs), it is possible in the case of VDOs toimplement a database comprising data to identify every single issuedVDO. This is as if the SEAO/VDO architecture is still to be implemented,and no hangover VDOs are to be considered in the design or therealization of the server or the VDO database. It is envisaged to use asystem such as known from the prepaid telephone cards to recharge theaccount of the telephone to implement a VDO-database. In this case themethod of this embodiment would further comprise generating an entry foreach generated VDO, and deleting said entry in case said VDO is cashedin.

In another example embodiment of the present invention said migrationserver is further provided with a database for specifically encryptedaccess objects (SEAOs). The data base for SEAOs comprises storageentries for (ideally all) circulating SEAOs and (ideally all) terminalunits SEAOs have been allocated for. The method of this embodimentfurther comprises deleting an entry of said first SEAO of said firstterminal unit in said data base for SEAOs, and generating a new entryfor said second SEAO of second terminal unit in said data base for SEAO.

By using and updating/maintaining the database for SEAOs the provider ofthe SEAOs can always determine if any request for migrating SEAO isauthorized or not. By using said database for SEAOs the provider of theSEAOs can always determine if a certain SEAO has been issued or not.This concept can be used for determining if a possibly executable SEAOhas been purchased or has been generated by illegal copying.

The method may be extended by determining that a certain SEAO stored ona terminal unit of a user is not longer valid, and deleting said SEAO.

This embodiment represents a kind of double entry bookkeeping for SEAOs.That is a provider of the SEAOs can always track the actual spreading ofissued SEAOs and is capable to determine e.g. an area of distribution ofsaid SEAOs. The provider of the database for SEAOs can access dynamicdata about the use and spread of said specifically coded access objects(and hence the spread of a respective execution of content).It should beclear that the database for SEAOs may be a place for storing said VDOsin.

In just another example embodiment of the method of the present saidmethod is extended by an operation for checking, if there is an entry ofsaid first specifically encrypted access object (SEAO) of said firstterminal unit in said data base for SEAOs. In case of a negativechecking result a migration refusal message may be generated, that canbe sent sending to said first terminal device and said the method can beterminated before a said entry is generated and/or before said secondSEAO is generated.

By implementing the checking operation it is ensured that a desiredmigration is actually determined, if there are any recordings ofpreviously performed allocation of a first SEAO to the first device. Itmay be implemented that in case that no entry of a first SEAO is presentin the data base (e.g. due to a hangover of “old SEAOs” from the timebefore the database has been established) then a presence of such anentry maybe assumed (resulting in a positive checking result), and a“negative entry” may be generated. Thereby, it can be prevented that asingle device with a number of pre-database SEAOs can use the databasefor providing an unlimited number of “officially” migrated SEAOs.

In case that there is such an entry, the method an be proceeded in aconventional manner. In case that there is no such an entry it isexpected that the first SEAO has not been obtained by the first devicein an intended manner. In case that there is no such an entry, it mayalso be expected that it has not been intended that the first SEAO hasbeen obtained by the first device. Thus, the method may be extended bythe step (of the following embodiment) of dispatching a command to thefirst terminal unit to delete said first specifically encrypted accessobject (SEAO). That is, if a terminal connects the migration center tomigrate a first SEAO, and there are actually no entries in the databasefor specifically encrypted access objects (SEAOs) the migration servermay construe that the first SEAO that must have been accidentallyprovided to the first terminal device. In this case the migration servermay delete the first SEAO from the memory of the first terminal.

By generating and sending a “migration refusal message”, in case of anegative checking result a user that tried to migrate a SEAO can beinformed that in the migration server's opinion a migration is to berejected. With the transmission of the migration refusal message, themigration can be terminated of interrupted, before said new entry and/orsaid second SEAO are generated.

According to yet another example embodiment said method furthercomprises dispatching a command to the first terminal unit to deletesaid first specifically encrypted access object (SEAO), via saidcommunication network. Thereby it may be assured that the firstspecifically coded access object is deleted on the first device (e.g.following or before the deliverance of a VDO or the second specificallycoded access object).

In still a further example embodiment of the present invention saidmethod further comprises the reception of a confirmation from said firstterminal unit, confirming that said first SEAO has been deleted.

According to just another aspect of the present invention a method forforwarding a voucher data object (VDO) via a terminal device isprovided. The method comprises receiving a VDO at said terminal devicevia a communication network, storing said VDO in a VDO storage saidterminal device and sending said VDO from said terminal device via saidcommunication network.

Deleting said VDO from said VDO storage may extend the method. Thereby,it can be assured that a user can not multiply a VDO for accessing anarbitrary number of secondary SEAOs. In the claims it has been left openwhether the terminal receives said VDO from a migration server or fromanother device. Similarly, it has been left open in the claims, whetherthe terminal sends said VDO to a migration server or to another device.Anyhow, it is intended that the VDO is transferred from the migrationserver to a first device, from the first device to a second device andback to the migration server. It does actually not matter if the VDO isreturned directly from the first device to the migration server as thisis also possible, if e.g. a user can not find someone to “pass” theSEAO. It may also happen that the VDO is transmitted to a third, fourth,fifth device before being transmitted to the second device for redeemingsaid VDO at the migration server for a secondary SEAO. It may be notedthat the VDO is provided for obtaining/migrating a SEAO. It may also benoted that the transfer of the VDO may be accompanied by transmissionsof first specifically encrypted access objects (SEAOs) of the firstterminal unit. It is also envisaged to transfer identification datarelated to said first terminal unit and to a content said first SEAO isdestined for. It is also contemplated to transfer additionallyidentification data related to said second terminal unit and a requestsfor issuing a second SEAO for said second terminal unit, and requestsfor issuing second SEAOs. Precautions could be taken that any backup ofa VDO is impossible. It may also be envisaged to implement means forassuring that the VDO is reliably deleted from the storage of thesending device in any case said VDO is sent.

In still another example embodiment of the present invention saidcommunication network is a cellular communication network and saidterminal device is a mobile cellular terminal of said cellularcommunication network. That is the present invention may be related to asystem for providing computer programs for terminal devices such as e.g.mobile phones or mobile phone enabled communicators. The presentinvention can also be used for delivering SEAO to e.g. video gameenabled cellular telephones. It is to be emphasized that thecommunication network of both methods, the method for migrating SEAOsand the method for forwarding VDOs can be executed in a cellular(mobile) (telephone) communication network.

According to yet another aspect of the invention, a software tool isprovided comprising program code means for carrying out the method ofthe preceding description when said program product is run on a computeror a network device.

According to another aspect of the present invention, a computer programproduct downloadable from a server for carrying out the method of thepreceding description is provided, which comprises program code meansfor performing all of the steps of the preceding methods when saidprogram is run on a computer or a network device.

According to yet another aspect of the invention, a computer programproduct is provided comprising program code means stored on a computerreadable medium for carrying out the methods of the precedingdescription, when said program product is run on a computer or a networkdevice.

According to another aspect of the present invention a computer datasignal is provided. The computer data signal is embodied in a carrierwave and represents a program that makes the computer perform the stepsof the method contained in the preceding description, when said computerprogram is run on a computer, or a network device.

According to just another aspect of the present invention a migrationserver of a communication network for migrating a specifically encryptedaccess object (SEAO) from a first terminal unit to a second terminalunit is provided. The migration server comprises an interface to saidcommunication network, a checking means, generating means for generatingsecond SEAOs and at least one storage.

Said interface to said communication network is provided forcommunicating with terminal devices. The migration server can receivee.g. a first SEAO of said first terminal unit and identification datarelated to said first terminal unit and to a content said first SEAO isdestined for via said communication network interface. The migrationserver can further receive identification data related to a secondterminal unit and a request for issuing a second SEAO for said secondterminal unit. Said interface is also capable of sending generatedsecond SEAO destined to said second terminal unit via said communicationnetwork.

The checking means is provided for checking if received requests areauthorized. The checking means is further connected to said interface(for obtaining said requests for the checking operation). The checkingmeans is configured to determine if a received request for a secondspecifically encoded access object is authorized or not.

The migration server is provided with a generation means for generatingsecond SEAOs. This generating means connected to said checking means,for generating a second SEAO for said second terminal unit, beingdestined for said content (said first SEAO has also been destined for).Said generating means is configured to generate said second specificallycoded access object according to a received identification data relatedto said second terminal unit, if said request is authorized (or a signalfrom the checking means is received indicating that the request isauthorized).

The at least one storage configured for storing SEAOs is provided in themigration server and is connected to said authentication means.

In an example embodiment said migration is further provided with a meansfor generating a voucher data objects. In this embodiment said interfaceto said communication network is also configured to send and receivevoucher data objects via said communication network. In this embodimentsaid checking means is configured to check also if a received voucherdata object is valid.

The use of VDOs implies that a user may request a VDO for a SEAO and maysubsequently exchange this VDO for the same SEAO said VDO has beenobtained for. This aspect is important, as the VDOs have been introducesto enable a migration of a SEAOs. If during a migration process thereason for this migration vanishes, a user should have a chance tomigrate the SEAO back to the first device. In this special case thefirst SEAO and the second SEAO are identical. In a slightly modifiedprocedure this back exchange may be used to provide updates for specialSEAOs to users.

In another example embodiment said migration server further comprises adatabase for SEAOs. The database comprises storage entries for (ideallyall) circulating SEAOs and (ideally all) terminal units SEAOs have beenallocated for. Said data base for SEAOs is connected to said a checkingmeans and to said generating means.

The data base for specifically encrypted access objects represents akind of “log file” or “family album” of the circulating SEAOs. Themigration server maintains and adapts the SEAO database by deletingentries of said “leaving” first SEAOs of said first terminal units insaid data base for SEAOSs, and generating new entries for said “beingmoving there” second SEAOs of second terminal units in said data basefor SEAOs. That is, the migration server acts as a kind of “registrationoffice” for SEAOs to ensure that SEAOs do not “reproduce” during anumber of migration procedures.

In still another example embodiment of the present invention saidcommunication network is a cellular communication network. That is,network server is a server of a cellular communication network, saidinterface is an interface to said cellular communication networkconfigured for receiving at least one terminal device identification ofa mobile cellular terminal device. That is, the present invention may berelated to a server configured for providing SEAOs for computer programsfor mobile cellular terminal devices such as e.g. mobile phones ormobile phone enabled communicators. The present invention can also beused to deliver SEAO to video game enabled cellular telephones.

According to just another aspect of the present invention a mobileterminal device is provided that is capable of forwarding voucher dataobjects (VDOs). The terminal device comprises a communication networkinterface, a central processing unit and a VDO storage. Said centralprocessing unit is connected to both said communication networkinterface and said VDO storage.

The mobile terminal device of the present invention is provided with thecapability to receive and send, i.e. to forward a voucher data object(VDO) via a communication network. In contrast to the number coded typedin prepaid mobile phones the voucher data object is also received viasaid communication network. It is also to be noted that the VDOs areissued and destined for migration servers and are provided for migratingSEAOs. That is, the terminal device is also capable of sending orreceiving SEAOs, terminal unit and identification data, and requests forissuing a second SEAOSs, or VDOs. In the claims it has been left openwhether the terminal is capable of receiving and sending VDOs to/from amigration server or to/from another terminal device. Precautions may betaken that any backup of a VDO is impossible. It may also be envisagedto implement means for assuring that the VDO is reliably deleted fromthe storage of the sending device in any case said VDO is sent.

It is further contemplated to provide the terminal device with a userinput interface (such as a e.g. a keyboard of a joystick) and with auser output interface (such as a display or a touch screen).

In an example embodiment of the present invention said mobile terminaldevice is a mobile cellular terminal device for a cellular communicationnetwork, such as a mobile telephone or a communicator. In this case saidcommunication network interface is an interface to said cellularcommunication network such as e.g. a GSM or UMTS radio module.

In the following, the invention will be described in detail by referringto the enclosed drawings in which:

FIG. 1 is a flowchart of a basic embodiment of the present invention formigrating a specifically encrypted access object (SEAO) from a firstterminal unit to a second terminal unit,

FIG. 2 represent a flowchart of a basic embodiment using a voucher dataobject (VDO) to migrate a SEAO from a first terminal unit to a secondterminal unit, using VDOs,

FIG. 3 visualizes the requirements for migrating a conventional SEAObetween different media,

FIG. 4 visualizes the “snow ball” effect,

FIG. 5 depicts a possible implementation of a system for migratingSEAOs,

FIG. 6 a and 6 b depict a specifically coded access object migrationmanaged by trusted online migration server,

FIG. 7 visualizes a look-up table containing information about whatspecifically coded access object is stored on which terminal unit,

FIG. 8 depicts how a check if transmission is allowed can beimplemented,

FIG. 9 visualizes a migration of a license by the use of look-up tablesand SEAOs transformation, and

FIG. 10 depicts a mobile terminal device configured for receiving andforwarding VDOs.

In the detailed description that follows, same or identical componentshave been given the same reference numerals, regardless of whether theyare shown in different embodiments of the present invention. In order toclearly and concisely illustrate the present invention the drawings maynot necessarily be to scale and certain features may be shown insomewhat schematic form.

FIG. 1 depicts a flowchart of a basic embodiment of the presentinvention for migrating a specifically encrypted access object (SEAO)from a first terminal unit to a second terminal unit. The initial stepshow the first terminal has acquired the first SEAO have been economized.It is expected that e.g. a user of the first terminal unit 16 wants toexecute a certain content on a second terminal unit 18 he obtained. Dueto the specificity of the specifically coded access object it is notpossible to transfer the first SEAO directly to the second terminalunit, e.g. because the devices have different private keys for decodingsaid SEAOs. The SEAOs can be delivered via a communication network suchas e.g. a cellular communication network. In the figures the terminaldevice is embodied as a mobile cellular terminal device and said acommunication network is embodied as a cellular communication networkwithout any limitation of the claims.

In the present scenario the user transfers the specifically coded accessobject from the first terminal unit to the migration server 2 via saidcellular communication network 14. The user may also transfer e.g. theinternational mobile device identification (IMEI) of the first device tothe migration server.

In a next step the second terminal unit 18 transfers 46 the deviceidentification of the second terminal unit 18 together with a requestfor the migration of said first SEAO of the first terminal unit 16 to asecond SEAO of the second terminal unit 18 to the migration server 2.

The migration server decrypts the received first SEAO according to thedata of the first terminal unit 16 to an unencrypted access object. Themigration server encrypts the unencrypted access object according to thedata of the second terminal unit 18 to a second SEAO.

Finally the migration server 2 sends the generated second SEAO to thesecond terminal unit 16 via said cellular network 14.

FIG. 2 represent a flowchart of a basic embodiment using a voucher dataobject (VDO) to migrate a SEAO from a first terminal unit to a secondterminal unit. The steps of FIG. 2 are comprised of the steps as thesteps of FIG. 1. In contrast to the method of FIG. 1 the migrationserver generates a VDO for the first terminal unit 16. The generated VDOis then transmitted 24 via said network 14 to the first terminal unit16.

The VDO received at the first terminal unit 16 can be passed on 40 to asecond terminal unit 18, directly or in turn via said network 14.

The second terminal then sends said received VDO via said network 14 tothe migration server 2. The voucher data can be used to authorize thesecond terminal unit 18 to request the generation and the transmission48 of a second specifically coded access object.

In FIG. 3 a terminal unit 16, which has received the SEAO via Internetdownload to an offline distribution storage medium (such as e.g. asecure MMC or an SD-card, or from one SD-card to another SD-card). Ifthe resale of SEAOs or the migration of SEAOs among different storagemedia is provided, this may open doors for hackers for bypassing theprotected paths of SEAOs, as the SEAOs cover all features (in anydigital format) to make any (specific) protected digital content usable.Conventionally the SEAO is uniquely bound to a single terminal unit 16,18 such as a mobile phone, a gaming console, a personal computer, apersonal digital assistant, a communicator or an online Server.

It is also envisaged to bind a SEAO to a certain storage medium such asan SD (Secure Digital) card or a (secure) multimedia card (MMC) servingas a terminal unit.

The transfer always requires a secure protocol to cover all secureoperations that are required to migrate (i.e. move and not copy) a SEAOin a secure way from the storage of terminal unit 16 to the storage ofterminal unit 18. This may require tamper-resistant hardware operationsthat may be included while executing a secure protocol. During transferthe SEAO needs to be released from terminal unit 16 and it also needs tobe bound to terminal unit 18.

It is clear that the transfer of the device would be simplesttransferred in an unencrypted way, but this would enable arbitraryunauthorized copying. That is, if a migration process is planned in aspecifically encrypted access object (SEAO) environment precautions maybe taken to prevent the “snowball-effect” (see FIG. 4).

FIG. 4 depicts a diagram showing the snowball effect that can occur whenone SEAO can unauthorized be multiplied to many SEAOs, which may be madeavailable for unauthorized downloads. That is, a single unauthorizedcopy of an unencrypted access object may spread fast undermining anyefforts to prevent unauthorized copying. If e.g. the same SEAO 110 ismoved to several devices 18, 19, 20 . . . or respective storage media,so that it can be used on devices or storage media independent fromterminal unit 16, there is no need for anyone to purchase a SEAO.

FIG. 5 depicts a possible implementation of a system for migratingspecifically encrypted access objects (SEAOs). The system of thedepicted embodiment comprises a cellular communication network 14,wherein two different terminal units 16, 18 are connected to saidcellular communication network 14. The online portal 12, e.g. a companyserver, is connected to said cellular communication network 14 forproviding public relations and representation. The online portal canalso be used for providing content, online interaction between terminalunits 16, 18 and the like. An access to the online portal can be grantedwith username, password and e.g. International Mobile EquipmentIdentification (IMEI).

The online portal can be provided with a content server 10 (for contentsuch as game titles and game features). The server can maintain allavailable online features. The online feature of interest is here the“Reselling of SEAOs”.

The online portal 12 or at least the content server 10 is to be capableof performing terminal unit authentication. A specific authenticationserver 8 can perform this authentication. The authentication can bebased on a mutual authentication based on a Public/Private keyinfrastructure. The terminal unit and the authentication server 8 can beprovided each with a unique private/public key pair.

The authentication server is connected to a migration server 2comprising a SEAO server or entity 4. The SEAO server 4 that checks thevalidity of the uploaded specifically encrypted access object (SEAO) orthe validity of parts of the uploaded SEAO.

The migration server 2 further comprises a voucher data object (VDO)server or entity 6. The VDO server can on demand generate a VDO. Therequest can be received or can be validated from SEAO server 4 justafter the validation of a received SEAO. It is also envisaged toimplement a connection from the VDO server 6 to the authenticationserver 8.

System, i.e. all components, but especially the terminal units 16, 18,the SEAO server 4, and the VDO server 6 can support a SEAO acquisitionprotocol (such as ROAP).

In the system the terminal units 16, 18 require a key pair of aprivate/public key pair for authentication and asymmetricencryption/decryption of the SEAOs. The terminal units 16, 18 shouldalso be capable of permanently deleting “voucherized” SEAOs.

As already indicated in FIG. 2 the method for migrating SEAOs can beimplemented according to the following procedure.

User connects with his terminal unit to the online portal 12 with e.g.username, password and IMEI

The user selects “Migrating of SEAOs” in the selection menu of theonline portal 12.

After mutual authentication the user has to select the SEAOs to bemigrated sold out of his domain.

The SEAOs or part of the SEAOs will be transmitted (e.g. via a ROAP)from the terminal unit 16 to the SEAO server 4 at the online portal.

The SEAO server 4 checks the validity of the received SEAOs

In case the SEAO server 4 authorizes the VDO server 6 to create a validVDO (wherein said voucher being assigned to a certain content e.g. agame title/game feature, video, audio or text data) of the receivedSEAOs. The created VDO is represented by a digital code, and maytherefore be called an e-voucher.

The e-voucher will be transmitted to the first terminal unit andseamlessly the specifically encrypted access object (SEAO) or entryinside the first terminal unit 16 will be deleted.

The user can now store, forward or sell the e-voucher to anybody or usethe e-voucher to migrate a certain SEAO to another terminal device.

FIG. 3 visualizes the requirements for migrating a conventional SEAO.

At present there are DRM standard for mobile devices and terminal unitsprecisely defining how online acquisitions for SEAO can be implemented(if a terminal unit 16, 18 requests a SEAO from a SEAO server e.g. via acellular communication network). However, there are no secure processesfor SEAO resale or SEAO migration. FIG. 3 visualizes the necessity for auser to migrate a SEAO from a first terminal unit 16 to another terminalunit 18.

FIGS. 6 a and 6 b depict a specifically coded access object migrationmanaged by trusted online migration server. FIG. 6 a shows a possibleimplementation of the general large area architecture, wherein an onlinemigration server 200 is involved in every transmission of a SEAO110,112. The migration server 200 contains a dedicated check instance108, which is capable of detecting non-authorized SEAO transmissions toprevent possible snowball effects. It is also envisaged to allow onlythe transmissions of SEAO to another terminal unit, and that for examplethe transmission from a terminal device to any storage card may not beexecuted. The migration server 200 is located on the online side andperforms all operations that are required to release a SEAO from aterminal unit 16. The migration server 200 also performs the requiredoperations that are necessary to bind the released SEAO to a newterminal unit 18. For that purpose the trusted online migration server200 is involved into the secure SEAO transmission protocol. Every timeif a SEAO transmission is to be performed in any direction the migrationserver needs to be contacted via a secure protocol. At a certain pointwithin the secure protocol the (transfer request for a SEAO) theterminal unit 16 hands over to the migration server 200 and provides themigration server 200 with necessary data such as unique SEAOidentification, unique terminal unit (i.e. medium or device)identification of both involved terminal units 16, 18. After handover tothe migration server it will be checked if the specifically encryptedaccess object (SEAO) transfer is allowed.

FIG. 6 b is a detailed diagrammatic view of a migration server 200. Themigration server 200 contains a dedicated check instance 108. Thechecking instance 108 can access a number of apply rules 122 forauthorized SEAO transmissions. The apply rules can be implemented in asimplest manner by a plausibility check, determining if a certain firstSEAO 110 is received from a terminal unit 16 that is capable ofexecuting a certain content. That is, in a simple case it is onlychecked if it is probable that the received license 110 is received froma probably authorized owner. I more sophisticated apply rules 122 it maybe envisaged to check if a certain first SEAO 110 has previously beensent from the terminal unit 16. This may indicate that the first SEAO110 has been back-upped and has been provided for retransmission toachieve two transferred SEAO. The second transmission may also indicatethat a user has repurchased the first SEAO 110 for a second time andwants to pass the repurchased first SEAO 110 to another terminal unit.

It is clearly visible that there are many different applicable applyrules 122 that may be implemented for the dedicated check instance 108,to decide if a requested transfer of a first SEAO 110 to anotherterminal unit 18 is authorized or not.

If the checking instance 108 determines that a requested transfer of aSEAO 110 is not authorized the transfer of the SEAO 110 to the terminalunit 18 is refused and the sending terminal unit 16 is notified aboutthis refusal. The generation of the notification that the requestedtransfer is not authorized can be implemented in a dedicated refusalinstance 124.

If the checking instance 108 determines that a requested transfer of aSEAO 110 is authorized a SEAO 112 encrypted according to the data of theterminal unit 18 is generated. The generated SEAO 112 is thentransmitted to the terminal unit 18, and the first terminal unit 16 isnotified about this transmission. It is also contemplated to implement adeletion of the first SEAO in terminal unit 16. This may be possible ifthe migration server has an online access to the terminal unit 16 and isprovided with the authority to delete the first SEAO 110 in the storageof the first terminal unit 16. The generation (and signing if required)of the specifically encrypted access object (SEAO) 112 can beimplemented in a dedicated preparing and signing instance 124. Thetransmissions of the SEAOs 110 and 112 can be performed via an extendedsecure protocol.

FIG. 7 visualizes a look-up table containing information about whatspecifically coded access object is stored on which terminal unit. FIG.7 shows a table with the information about which SEAO is stored on whichmedium (or terminal unit), which can be managed very time-efficient.

The table may comprise an entry (or a “sub-table”) 300, 302, 304, . . .3XX for each terminal unit. The look-up table contains an entry forevery terminal unit that stores a SEAO, it may also be envisaged toimplement an entry for each terminal unit that can store a SEAO or oncehas stored a SEAO. That is, each terminal is registered with a uniqueterminal unit identification id(x) 400 identifying a terminal device (x)or a storage medium (x).

Each terminal unit identification id(x) 400 is allocated a number(including zero) of SEAO identifications id(L₁), id(L₂), . . . id(L_(n))420 stored on the terminal unit 3XX. Id(L_(n)) is a SEAO identifier fora SEAO that might be composed of more elementary SEAOs informationcomponents. The SEAO identifications can be implemented as a SEAO tree.This SEAO tree can contain the information of which SEAO has beeninstalled on each of the entities being involved in a transfer of aSEAO. It is also envisaged to implement a kind of history table toaccess information about the utilization chain of each SEAO. Thisinformation would enable to predict a certain course of spreading of acertain content or of certain SEAOs. This would also enable anadaptation of selling conditions for new SEAOs.

Each of the SEAO identifications id(L₁), id(L₂), . . . id(L_(n)) 420 isallocated with a number of elementary access object 440.

The use of this table allows to trace the transfer of all SEAOs.

FIG. 8 depicts an implementation of check for determining iftransmission is allowed or not. The description of “authorizedtransactions” can be given as set of rules that define an authorizedmigration and/or as a set of rules defining unauthorized migrations.FIG. 8 depicts a simple example implementation. Every transmission of aspecifically encrypted access object (SEAO) can anonymously be logged,and the migration server 200 (or the checking instance 108) has alwaysthe knowledge about the state (and the storage) of all circulatingSEAOs. This enables an easy detection of unauthorized attempts tomigrate a SEAO. The information about which SEAOs are stored on whichterminal unit can be stored in a database table (as depicted in FIG. 7).The database table can be managed very time-efficient. If the migrationof a first SEAO 110 from terminal unit 16 to terminal unit 18 isallowed, the migration server 200 prepares the second SEAO 112 for thereceiving terminal unit 18. As defined in the preceding text a terminalunit can be everything that is capable of storing SEAOs. Finally theSEAO 112 is signed. With the signing process it is prevented thatanybody (or any device) else beside the migration server 200 is capableof performing those generation of said second SEAOs 112. If the transferof a first SEAO 110 is allowed and the second SEAO 112 has been preparedfor usage on the destination terminal unit 18, the migration server 200hands over back to the second terminal unit 18 and sends the preparedsecond SEAO 112 to the requesting terminal unit 18. Finally the secondterminal unit 18 continues performing the secure protocol with thesecond SEAO 112.

FIG. 9 visualizes a migration of a license by the use of look-up tablesand SEAOs transformation. The idea behind the apply rules 122 in thechecking instance 108 can be implemented in a very simple way by justfollowing the principle that a terminal unit entity can only transfer ormigrate those SEAOs that this terminal unit has received before. It isestimated that migration cannot be authorized if a terminal unit shalltransfer a SEAO it never has received before.

It may also not desirable that an entity shall receive a SEAO (with aunique serial number etc.) a second (third or more) time. In thesementioned (very simple) cases, the migration server may not perform thetransfer of the SEAO. Thus any duplication of SEAOs can be prevented.Depending on the selected apply rules 122 for authorized migrations ofSEAOs the checking procedure may become much more complex.

According to the invention a transfer from a first terminal unit 16 toanother second terminal unit 18 always requires the involvement of themigration server 200 as a trusted intermediary. If specificallyencrypted access objects (SEAOs) between two entities (without anyonline connection) shall be exchanged an authorized device has to workas connection intermediary (which is not to be mixed up with the trustedintermediary on the online side!).

It is envisaged to use a public/private key infrastructure to encode theSEAOs, wherein the migration server and other authorized entitiesrequire an access to these keys.

In summary the migration server is a protected online server, whichoperates on a kind of SEAOs database and performing a kind of doubleentry bookkeeping for all circulating SEAOs. The migration server iscontacted (using a secure protocol) if a migration of a SEAOs isrequested by a terminal unit. The migration server 200 is provided withnecessarily unique identification data 300-3XX of all involved entitiesand the uniquely identification data of the SEAOs 420. As uniqueidentification data the may be implemented as e.g. certificates of thetwo terminal units involved in the migration of the SEAO. Usingprivate/public key infrastructures may enable this. The SEAO should alsohave a kind of unique identification, maybe a kind of serial number. Allin the entities (terminal unit and servers) embedded in the environmentand the circulating SEAOs are managed within a surveillance or trackingtable (see. FIG. 7). Due to the great number of entities and the greatnumber of SEAOs the tracking table the data content may be veryextensive.

It is contemplated that an entry in this table is allocated to eachterminal unit if it (at all) receives a SEAO for the first time. Thisentry contains the root of the terminal unit SEAOs tree, which containsall SEAOs identifiers. The check if a terminal unit has a SEAOs isperformed within this SEAOs tree. If an entity owns a SEAOs the SEAOsidentifier id(L) is found in this tree. The search can be implemented ina very time-efficient manner. Also the operations to release a SEAOsfrom a terminal unit can be implemented very time-efficient.

These operations are operations as commonly implemented for tree datastructures. If a specifically encrypted access objects (SEAOs) is to bereleased from an entity 16, the corresponding sub-tree (that finallycontains all information related to this SEAOs) is taken out of theSEAOs tree for terminal unit 16. The owner of this SEAOs simply changesif this taken sub-tree is embedded into the SEAOs tree of the new SEAOsowner 18.

FIG. 10 depicts a mobile terminal device configured for receiving andforwarding voucher data objects (VDOs). The mobile terminal is providedas a conventional mobile terminal with an interface 500 to a radiocommunication network via an antenna. The terminal device is embodied asa conventional mobile cellular terminal with a central processing unit(CPU) 502. The CPU 502 is connected to microphone, a keyboard, a displayand a loudspeaker to provide conventional mobile terminal functionality.The terminal device is also provided with a dedicated voucher dataobject (VDO) storage 510 to store VDOs that have been received from avoucher server as depicted e.g. in FIG. 2 or 5. A user can use thedevice to pass on a VDO to another terminal device via said interface500. It is also envisaged that a user may use e.g. another interfacesuch as a short-range radio or an Infrared interface (not depicted) toreceive or send a VDO from or to another terminal device. When userwants to cash-in a stored VDO, the VDO is transferred from the VDOstorage 510 via CPU 502 and the interface 500 to a migration server (notdepicted) together with identification data of the terminal device.

The invention may be used (partly) for mobile products, especially foroffline distribution media and resell of SEAOs. The invention can beinterpreted as an extension to an applied digital rights managementstandard (as e.g. the OMA DRM standard), which until today only supportsonline operations of SEAOs and excludes offline SEAOs operations.

It is very difficult to circumvent the migration server 200 as trustedintermediary, because it is an online server, which can only berequested by authorized terminal units, and several protectiontechniques can be implemented to protect the online migration server 200against e.g, hacker attacks.

It is not easy to fake an SEAO, because they are signed and modified (inorder to change the terminal unit) only on the protected trusted onlinemigration server side. That is, there are no offline operationsperformed, which may be imitated or hacked to enable the undesiredunauthorized copying and/or migrating.

However, it is to be noted that the present invention is claimed with aSEAO. The expression “comprising” has been selected in the claims toencompass the migration of more than one single SEAO also. For the sakeof conciseness and clarity the laborious phrases “ . . . at least one .. . ” and “ . . . at least one of said at least one . . . ” have beenavoided in the claims.

With the invention the user of a SEAO (e.g. a SEAO of a video game) willbe able to pass on, give away or sell SEAOs (and thus also video games).The SEAOs can be traded (e.g. in an online auction) as commercial goods.

The present invention allows the control and the surveillance ofcirculating SEAOs from several perspectives. The spreading ofunauthorized copies of specifically encrypted access object (SEAO) andespecially the “snow ball effect” can be prevented. With the presentinvention is possible to detect unauthorized copies of SEAOs.

The present invention allows for fast reactions in case of detectedunauthorized SEAOs, (by at least refusing unauthorized transfers SEAOs)

The method of the present invention is difficult to circumvent, becausethe migration server (e.g. as a protected online server) can beprotected well by firewalls and high level access restrictions.

SEAOs cannot be faked, because only the migration server on theprotected online side will perform the change of the allocation of theSEAOs to a certain terminal device.

The methods and devices of the present invention allow for the firsttime offline distribution media (such as secure memory cards) being partof a closed DRM-based SEAOs distribution system.

Even if it should be possible to copy a SEAO from one secure memory cardto another, the copied SEAOs would not work for the new card, becausethe trusted intermediary is the only instance that is capable ofpreparing the SEAOs for new media (->by giving mandatory digitalsignatures).

This application contains the description of implementations andembodiments of the present invention with the help of examples. A personskilled in the art will appreciate that the present invention is notrestricted to details of the embodiments presented above and that theinvention can also be implemented in another form without deviating fromthe characteristics of the invention. The embodiments presented aboveshould be considered illustrative, but not restricting. Thus thepossibilities of implementing and using the invention are onlyrestricted by the enclosed claims. Consequently various options ofimplementing the invention as determined by the claims, includingequivalent implementations, also belong to the scope of the invention.

1. Method comprising: receiving, via said communication network, a firstspecifically encrypted access object of said first terminal unit, andidentification data related to said first terminal unit and to a contentsaid first specifically encrypted access object is destined for;receiving, via a communication network, identification data related tosaid second terminal unit, and a request for issuing a secondspecifically encrypted access object for said second terminal unit;checking if said request is authorized; generating, if said request isauthorized, a second specifically encrypted access object for saidsecond terminal unit, being destined for said content; and sending, viasaid communication network, said generated second specifically encryptedaccess object destined to said second terminal unit.
 2. Method accordingto claim 1, further comprising: generating a voucher data object, forthe generation of a specifically encrypted access object for anotherterminal unit for said content; sending said voucher data object, tosaid first terminal unit via said communication network; receiving saidvoucher data object, from said second terminal unit via saidcommunication network; wherein said checking operation if said requestis authorized comprises checking if said received voucher data object isvalid.
 3. Method according to claim 2, wherein said receiving of saididentification data related to said second terminal unit and of saidrequest for issuing a second specifically encrypted access object forsaid second terminal unit via a communication network and said receivingof said voucher data object are performed substantially simultaneously;and wherein said generating said second specifically encrypted accessobject for said second terminal unit, and said sending of said generatedsecond specifically encrypted access object destined to said secondterminal unit are performed substantially successively.
 4. Methodaccording to claim 2, further comprising storing said voucher dataobject in a memory of said server.
 5. Method according to claim 1,wherein said migration server further comprises a database forspecifically encrypted access objects, said database comprising storageentries for circulating specifically encrypted access objects andterminal units specifically encrypted access objects have been allocatedfor, said method further comprising: deleting an entry of said firstspecifically encrypted access object of said first terminal unit in saiddatabase for specifically encrypted access objects; and generating a newentry for said second specifically encrypted access object of secondterminal unit in said database for specifically encrypted access object.6. Method according to claim 5, further comprising: checking if there isan entry of said first specifically encrypted access object of saidfirst terminal unit in said database for specifically encrypted accessobjects; and in case of a negative checking result generating amigration refusal message; sending said migration refusal message;terminating the method before generating said new entry and/or beforegenerating a second specifically encrypted access object.
 7. Methodaccording to claim 1, further comprising dispatching, via saidcommunication network, a command to the first terminal unit to deletesaid first specifically encrypted access object.
 8. Method according toclaim 7, further comprising receiving a confirmation from said firstterminal unit that said first specifically encrypted access object hasbeen deleted.
 9. Method, comprising: receiving, via a communicationnetwork, a voucher data object at a terminal device; storing saidvoucher data object in a voucher data object storage of said terminaldevice; and sending, via said communication network, said voucher dataobject from said terminal device.
 10. Method according to claim 1,wherein said communication network is a cellular communication networkand said terminal device is a mobile cellular terminal of said cellularcommunication network.
 11. Machine-readable medium comprising programcode sections to instruct a controller, processor-based device, acomputer, a microprocessor based device, a terminal, a network device, amobile terminal, or a mobile communication-enabled terminal to: receive,via a communication network, a first specifically encrypted accessobject of a first terminal unit, and identification data related to saidfirst terminal unit and to a content said first specifically encryptedaccess object is destined for; receive, via a communication network,identification data related to a second terminal unit, and a request forissuing a second specifically encrypted access object for said secondterminal unit; check if said request is authorized; generate, if saidrequest is authorized, a second specifically encrypted access object forsaid second terminal unit, being destined for said content; and send,via said communication network, said generated second specificallyencrypted access object destined to said second terminal unit. 12-14.(canceled)
 15. Server, comprising: an interface coupled to acommunication network for receiving a first specifically encryptedaccess object of a first terminal unit, and identification data relatedto said first terminal unit and to a content said first specificallyencrypted access object is destined for, and identification data relatedto a second terminal unit and a request for issuing a secondspecifically encrypted access object for said second terminal unit; achecking instance connected to said interface for checking if saidreceived request is authorized; generating means for generating secondspecifically encrypted access objects, said generating means beingconnected to said checking instance, said generating means beingconfigured for generating a second specifically encrypted access objectfor said second terminal unit being destined for said content; at leastone storage connected to said checking instance; wherein said checkinginstance is configured to determine if a received request for a secondspecifically encoded access object is authorized; said generating meansis configured to generate said second specifically coded access objectaccording to a received identification data related to said secondterminal unit, if said request is authorized; said storage is configuredto store specifically encrypted access objects; and said interface isconfigured to send said second specifically encrypted access objectdestined to said second terminal unit via said communication network.16. Server according to claim 15, further comprising: means forgenerating a voucher data object; wherein said interface to saidcommunication network is further configured for sending and receivingvoucher data objects via said communication network; and said checkinginstance is configured to check if a received voucher data object isvalid.
 17. Server according to claim 15, further comprising a databasefor specifically encrypted access objects; wherein said databasecomprises storage entries for circulating specifically encrypted accessobjects and terminal units specifically encrypted access objects havebeen allocated for; and said database for specifically encrypted accessobjects is connected to said checking instance and to said generatingmeans.
 18. Server according to claim 15, wherein said network server isa server of a cellular communication network, said interface is aninterface to said cellular communication network and is configured forreceiving at least one terminal device identification of a mobilecellular terminal device.
 19. Device, comprising a communication networkinterface; a central processing unit; and a voucher data object storage;wherein said central processing unit is connectable to both saidcommunication network interface and said voucher data object storage.20. Device according to claim 19, wherein said terminal device is amobile cellular terminal device for a cellular communication network,and said communication network interface is an interface to saidcellular communication network.
 21. Device, comprising: means forreceiving a first specifically encrypted access object of said firstterminal unit via a communication network; means for receivingidentification data related to said first terminal unit and to a contentsaid first specifically encrypted access object is destined for; meansfor receiving identification data related to said second terminal unit;means for receiving a request for issuing a second specificallyencrypted access object for said second terminal unit; means forchecking if said received request is authorized; means for generating asecond specifically encrypted access object for said second terminalunit being destined for said content; means for storing specificallyencrypted access objects; means for determining if a received requestfor a second specifically encoded access object is authorized; means forgenerating said second specifically coded access object according to areceived identification data related to said second terminal unit, ifsaid request is authorized; means for sending said second specificallyencrypted access object destined to said second terminal unit via saidcommunication network.
 22. A server comprising: an interface coupled toa communication network for receiving a first specifically encryptedaccess object of a first terminal unit, and identification data relatedto said first terminal unit and to a content said first specificallyencrypted access object is destined for, and identification data relatedto a second terminal unit and a request for issuing a secondspecifically encrypted access object for said second terminal unit; atleast one storage; a processing module configured to determine whetherthe received request is authorized and to generate at least one secondspecifically encrypted access object for said second terminal unit beingdestined for said content, and further configured to determine whether areceived request for a second specifically encoded access object isauthorized; and wherein said at least one storage is configured to storespecifically encrypted access objects, and said interface is configuredto send said second specifically encrypted access object destined tosaid second terminal unit via said communication network.